假设有个计算类: Calculator, 需要调用 Calculator.add() 来执行加法运算, 可以直接生成一个 Calculator 对象, 调用 add() 即可.

这就是本地函数调用, 因为在同一个地址空间, 所以通过方法栈和参数栈就可以实现.

在分布式架构下, Calculator 在 A 主机的服务中运行, 为其他服务提供计算功能.

B 主机中的服务想执行加法计算, 如何调用 A 主机的 Calculator.add()?

RPC 要解决的两个问题: 1 解决分布式系统中, 服务之间的调用问题; 2 远程调用时, 要能够像本地调用一样方便.

思路: 1 可以使用 http 协议来进行数据传输; 2 使用 Socket 等方式进行二进制传输.

http 接口适用于接口不多, 系统与系统交互较少的情况, 简单直接, 开发方便, 利用现成的 http 协议进行传输;

如果是大型网站, 内部子系统较多, 接口较多的情况下, RPC 接口的好处就显现出来了. 1 长连接. 不必每次通信都像 http 一样进行 3 次握手, 减少网络开销; (不是很靠得住, http 开启 keepalive 后只需 1 次握手) 2 注册中心. RPC 框架一般都有注册中心, 有丰富的监控管理, 发布, 动态扩展等, 对调用方来说是无感知的; 3 安全性. (这点 SSL 也安全)

总的来说, RPC 可以解耦服务, 提高灵活性, 提高效率.

如果使用二进制传输, 最重要的就是序列化和反序列化, 将对象序列化成二进制格式, 到了 Server 再反序列化为对象.

CS 之间遵守相同的接口规范, S 端需要保存数据.

一次请求就是一次完整的操作, S 端不依赖前后不同请求的顺序和状态来完成一次操作. 如果所需数据需要通过多次请求才能完成, C 端要自己负责记录状态.

C 端持有 session, S 端使用 session 信息去验证并执行相关操作.

合理的缓存设计可以减少请求次数, 进而提高 S 端的效率和性能.

C 端不知道数据是从 S 端直接返回还是通过中间代理返回, 提高了系统的可扩展性, 可以使用负载均衡和反向代理等技术来对系统进行水平扩展和缓存处理, 把系统划分成不同的层次. 使用分层设计也方便管理不同资源的权限, 提高系统的安全性.

S 端可以返回一些代码让客户端执行, 从而定制和扩展 C 端的功能.

一致的接口可以降低子系统之间的耦合度, 因为子系统只要关注实现接口即可. 一致的接口包括四个方面:

1. 一致的数据格式;
2. 可以对已有数据进一步操作. 如从服务端获得了一个订单数据, 这个订单数据里应该保证有一个唯一的订单 ID, 当我们想对这个订单进行进一步操作时, 可以保障操作的是同一个订单;
3. 数据具有自我描述性. 如, 通过 HTTP 返回的数据里面有 [MIME type] 字段, 通过该字段可知数据是图片, 视频还是别的.
4. 应用系统状态变化只依赖超媒体. 如向一个微博 Web Service 请求一条微博信息, 服务端响应信息中应该包含和这条微博相关的其它的URL, 客户端可以进一步利用这些URL发起请求来获取感兴趣的信息; Facebook API 可以从第一页的返回数据中获取下一页的 URL.

RESTful Web Service API 简单为 RESTful API, 一般来说, 这类 API 是通过 HTTP 协议以 URL 形式暴露给其他系统或模块调用, 如, 一个获得用户所有评论的 API 可能像这样: https://api.server-name.com/user-id/comments